1. Field of Invention
The present invention relates in general to the digital data processing field and, more particularly, to a computer-implemented method, apparatus, and computer program product for implementing a requester-side autonomic governor in a Service Oriented Architecture (SOA) architected system.
2. Background Art
In the latter half of the twentieth century, there began a phenomenon known as the information revolution. While the information revolution is a historical development broader in scope than any one event or machine, no single device has come to represent the information revolution more than the digital electronic computer. The development of computer systems has surely been a revolution. Each year, computer systems grow faster, store more data, and provide more applications to their users.
Years ago, computers where stand-alone devices that did not communicate with each other, but today, computers are increasingly connected in networks and one computer, called a client, may request another computer, called a server, to perform an operation. With the advent of the global Internet, this client/server model is increasingly being used in online businesses and services, such as online commerce, banking, auction houses, stock trading, and information storage and retrieval. The client/server model is also used in local intranets.
Two current techniques for connecting clients and servers are called Service Oriented Architecture (SOA) and Utility Computing. A service-oriented architecture includes a collection of services, which communicate with each other. Typically, a service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. The communication between the services may involve either simple data passing between two or more services, or may involve two or more services coordinating some activity.
Utility computing is a service provisioning model in which a service provider makes computing resources available to a customer as needed, and charges customers for a specific usage of the resource rather than a flat rate. Like other types of on-demand computing (such as grid computing), the utility model seeks to maximize the efficient use of resources and/or minimize associated costs. Another version of utility computing is carried out within an enterprise in a shared pool utility model. In the shared pool utility model, an enterprise centralizes its computing resources to serve a larger number of users without unnecessary redundancy.
In both the Service Oriented Architecture and Utility Computing, the client determines the server that is to receive and process a request, and the client may have multiple requests that it sends to multiple servers. Each server processes its received requests and sends responses to the client that originated the request.
An SOA can provide a consistent, re-usable method for integrating any type of information consumer with any business process or information provider. In the SOA, a set of services can be defined that provide application functions. These services can serve as an abstraction layer that hides core system details from clients and provides a simple way to integrate consumers and service providers based upon standardized protocols, such as XML, WSDL, and SOAP.
Service oriented architectures are characterized by the use of service invocations as the basic building block for distributed systems, whether those systems are loosely coupled or tightly coupled. A service invocation is a call for a service to be performed. Examples of service invocations include simple service invocations, such as instructions to get the current time in UTC; or service invocations to, given a metric unit of measure, produce the equivalent English system of measure. Other examples of service invocations include more complex service invocations, such as instructions to, given an item number, produce the quantity of that item which is stocked in a warehouse or retail store; or instructions to, given a list of items and a customer account number, place an order with a retail enterprise for those items on behalf of the referenced customer.
In an SOA, a client can invoke a service within a component to perform an operation and, optionally the client can receive a response. Invoked services can include, for example, business services configured to fulfill the needs of business customers, whether those customers are individual consumers or other businesses. The services can be grouped into various SOA components where each component can specialize in functions such as catalog management, shopping cart management, credit card transaction processing, sales tax computation and the like.
Typically, a provider of a synchronous service in an SOA has a limited amount of resources or requests that it can support at one time. Hence, one or more clients may simultaneously invoke a synchronous service and overwhelm the service provider with too many requests. Often there is no Message Queuing infrastructure in place to manage and/or control these requests. In some cases it is not possible to apply additional resources or modifications to the service provider. For example, the client, while interested in obtaining the service from the provider, may be an unrelated party with respect to the service provider and, hence, have little or no interest in increasing the provider's capacity. Moreover, the service provider may not find it cost effective to apply additional resources or modifications. In effect, the popularity of the service has caused the provider to experience Quality of Service (QOS) issues. These Quality of Service issues will likely impact the clients invoking the service and, perhaps, cascade to clients of those clients.
These Quality of Service issues may lead clients invoking the synchronous service to develop their own functionality similar to that of the service, especially in cases where demand for the service is increasing or is forecast to increase and/or the requesting application is to be rewritten. Typically, however, continued use of the existing service by the requesting application or re-use of the existing service by the rewritten requesting application is preferred because of the cost and delay that must borne in developing the functionality. In some cases, it may not even be possible for the client to develop the functionality.
Therefore, a need exists for an enhanced mechanism for invoking a synchronous service in a Service Oriented Architecture (SOA) architected system.